The Push Notifications Console now includes metrics for notifications sent in production through the Apple Push Notification service (APNs). With the console’s intuitive interface, you’ll get an aggregated view of delivery statuses and insights into various statistics for notifications, including a detailed breakdown based on push type and priority. Introduced at WWDC23, the Push Notifications Console makes it easy to send test notifications to Apple devices through APNs. Learn more.

Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

I'm seeing a timestamp display issue on Apple Watch Notification Center, and I'd like to confirm whether this is a known watchOS behavior or whether there's a setup mistake on our side. Symptom The same APNs notification displays the correct time on iPhone Notification Center and on the initial Apple Watch banner. After the Watch screen turns off and the user later opens Notification Center on Apple Watch, the same notification may show an incorrect relative timestamp such as "3 hours ago" or even "yesterday". The drift is per-notification and persists for that notification until it's dismissed. iPhone NC always shows the correct time. WhatsApp tested side-by-side on the same iPhone/Watch pair does not show this drift. Setup iOS 26.4.2 on iPhone 16 Pro watchOS 26.4 on Apple Watch Series 10 App with paired Apple Watch A UNNotificationServiceExtension that decrypts E2EE message previews and applies Communication Notification enrichment via INSendMessageIntent and content.updating(from:) Production APNs environment, TestFlight builds No beta software Isolation tests already performed Test mutable-content NSE invoked Drift on Watch NC Minimal APNs (alert + sound only) no no no drift NSE skips content.updating(from:), INInteraction.donate/delete (still calls them as no-op via diagnostic build) yes yes — modifies content drift NSE bypasses ALL Intents/Communication Notification APIs (no INPerson, no INSendMessageIntent, no avatar, no updating(from:)); just modifies title/body/sound/category and returns the mutable copy yes yes — modifies content drift Production-like APNs payload (thread-id, target-content-id, category, sound, badge, custom userInfo) but WITHOUT mutable-content no no no drift Eliminated as causes: content.updating(from:), INSendMessageIntent, INInteraction.donate, INInteraction.delete(with:), INPerson/INPersonHandle (not even constructed in test 3), avatar fetching, thread-id, target-content-id, category, sound, badge, custom userInfo, custom createdAt timestamp, stale Siri/Apple Intelligence history (cleared manually on iPhone and Watch). The pattern The only consistent variable distinguishing the no-drift cases from the drift cases is whether mutable-content: 1 is set on the APNs payload (i.e. whether the UNNotificationServiceExtension is invoked). Once invoked, the extension's behavior with respect to Communication Notifications does not seem to affect the outcome — the drift reproduces even when the NSE only modifies title/body/sound and returns. Questions Is there a known watchOS behavior where notifications processed by a UNNotificationServiceExtension use a different timestamp source on Apple Watch Notification Center after the Watch screen has been turned off and reopened, while the initial Watch banner and iPhone Notification Center show the correct delivery time? Are there specific UNMutableNotificationContent properties or APNs payload flags that should be preserved (or avoided) when returning content from an NSE to keep the Watch NC timestamp consistent with the delivery time? For E2EE messaging apps, is there a recommended pattern to decrypt and return content from an NSE that avoids this drift on watchOS? Happy to provide an anonymized snippet of NotificationService.swift and the APNs payload format if useful. Thanks.

Hi everyone, I have a question about Live Activity start tokens and update tokens. After reading the documentation, it is still not very clear to me how often these tokens are invalidated, and whether their expiration is time-based or event-based. My current understanding is that the update token is generated when the Live Activity starts, and that it becomes invalid when the activity ends or is dismissed by the user. What I am not clear on is whether the update token can also become invalid at any point while the Live Activity is still active. I have a similar question about the start token. I have noticed that it is generated on the initial app launch, but I have also seen it get regenerated at what seems like random times. I would like to better understand what events or conditions cause a new start token to be issued. Is there any official guidance on the lifecycle of these tokens, specifically: whether they expire based on time, whether they are only invalidated by specific events, and what conditions trigger regeneration of the start token or update token? Any clarification would be appreciated. Thanks.

Hi everyone, I have two questions about Live Activity push notifications that we send from our backend server to iPhones. First, I would like to understand the expected behavior when lowering the APNs priority of a Live Activity update from 10 to 6. How does this affect delivery timing, reliability, or system handling of the notification? Second, my team has been seeing significant delays with some messages sent to the device. In some cases, notifications take anywhere from 1 to 3 hours to arrive on the phone. We are trying to understand what might cause this kind of delay. Is this expected under certain conditions, such as device state, system throttling, network conditions, or APNs behavior? Also, is there any way to inspect logs or delivery details for messages sent to the app so we can better diagnose where the delay is happening? Any guidance would be appreciated. Thanks.

I have a live activity and even after a couple of times that it has shown on my lock screen it keeps prompting the user to tap on Don't Allow or Allow. Can someone help me understand why this is happening? I would like my users to only hit Allow once and not be prompted again, otherwise they would not be registered for updates, since update token only generates after selecting Allow.

We have an app that uses PushKit and CallKit for video calling. These are often emergency calls, so very latency-sensitive. We keep track of when we sent out the APNs request and when the phone started ringing. The p95 latency is about 2 seconds (mean is ~800ms), which feels quite long.. Is this normal? I'd expect <500ms most of the time given that the devices and servers are all within the US. The users typically have a stable internet connection. Our requests look like this: POST https://api.push.apple.com/3/device/<DEVICE_TOKEN> apns-topic: com.vpt.physician.voip apns-push-type: voip apns-priority: 10 apns-expiration: 0 authorization: bearer <APNS_PROVIDER_TOKEN> content-type: application/json {  "aps": {    "content-available": 1  },  "title": "Example Text",  "type": "CallFromTablet",  "timeout_ms": 30000 } If there's any more info I can provide to help troubleshoot this, let me know. Thanks in advance.

In my VoIP app, we use StartRing and StopRing via VoIP push to my app. But recently, I found some disordered VoIP notifications, my VoIP app received the StopRing push before the StartRing push. Examples: Server log: // send StartRing startring: - Apr 9, 2026 @ 14:54:43.255 .."pushType":"voip","priority":10, ... // send StopRing stop-ring Apr 9, 2026 @ 14:54:47.645 ..."pushType":"background","priority":5,"... VoIP app log: // receive StopRing 2026-04-0909:54:48.858 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StopRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 // receive StartRing 2026-04-0909:54:49.524 CDT : INFO : [RcRtc] [0x1feeba1c0] [PushNotificationParser]call push notification handled. action: StartRing telephony session id: s-a0dd8601926c7z19d72bbf8b9z1e62ec10000 sid: 178503189447188 Then we can see the StartRing send first, but received in the app after the StopRing. The StartRing took abunt 6s to send and the StopRing took about 1s. So I guess there is an issue in the APNs part on iOS26.4. We saw there is a peak after iOS26.4 and iOS 26.4.1 than old iOS versions. Thanks.

Hey guys, I made a app that features push notificaions, and I keep having problems setting them up. It asks permissions, and then it says that it cannot get the APN token after 10 seconds, and I am positive that I have enabled Push Notificaions in the provisioning profile in Xcode. Can anyone help me fix this issue?

Hello, We are experiencing an issue related to push notifications after updating devices to iOS 26.4 Beta. Our system stores push notification tokens on the server by associating the device token with the device’s IDFV in the app. After updating a device to iOS 26.4 Beta, we observed that the device token from a previously uninstalled version of the app remains valid for more than a week. As a result, two push notifications are delivered to the same device. The situation is as follows: The user installs the app and a device token is generated. The user uninstalls the app. Later, the user installs the app again and a new device token is generated. However, the previous device token does not become invalid, even after more than a week. Because IDFV changes when the app is reinstalled, our server cannot determine that the device belongs to the same user. Therefore, we cannot overwrite the old token with the new one on the server side. Could you please advise: Is this behavior expected in iOS 26.4 Beta? How long does it normally take for a device token to become invalid after an app is uninstalled? What is the recommended approach to prevent duplicate push notifications in this situation? Any guidance would be greatly appreciated. Best regards

Description When starting Live Activities via ActivityKit push notifications, the “start” notification is received correctly on iPhone 16 Pro Max, but subsequent update or end push notifications are not. The same implementation on iPhone 16 Pro behaves as expected (both start and update/end notifications are delivered and processed). Environment Property Value Device (failing) iPhone 16 Pro Max Device (working) iPhone 16 Pro iOS Version 18.5 Xcode / SDK 16.2/ActivityKit / Push Notifications Network Wi-Fi / Cellular (both tested) Data Collection Method Devices connected via USB. Logs captured using Console.app. Log filtering applied for the liveactivitiesd daemon to isolate Live Activity behavior. Initial Triage/Observations Payload format confirmed compatible; no incompatible fields. APNs token remains the same across messages (no refresh). Identical ActivityKit subscriptions/participants on both devices. Server-side delivery is confirmed: iPhone 16 Pro receives all messages (start, update, end). Only iPhone 16 Pro Max fails to receive update or end push notifications. Log Analysis iPhone 16 Pro (Working) Push-to-Start successfully received: 13:45:20 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:45:20 - Received message: eventType: start(SessionPushNotifications.IncomingMessage.EventType.StartParameters(attributesType: "AchToLSUpgradeAttributes", attributesData: 125 bytes, inputs: [])) 13:45:20 - Created activity: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 13:45:45 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:45:45 - Received message: eventType: end(dismissDate: Optional(2025-07-21 21:00:44 +0000)) 13:45:20 - Activity updated: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 13:45:20 - Local activity did update: 1C081AC5-01AE-4EC0-8B67-5F2A9FAE2D60 iPhone 16 Pro Max (Failing) 13:56:39 - APSXPCDeliverMessageEvent: Created APSIncomingMessage 13:56:39 - Received message: eventType: start(SessionPushNotifications.IncomingMessage.EventType.StartParameters(attributesType: "AchToLSUpgradeAttributes", attributesData: 125 bytes, inputs: [])) 13:56:39 - Created activity: E6BBF691-0C7A-4791-98D2-6F1440D9932E **No subsequent APNs push-to-update or push-to-end messages received.** 13:56:39 - No destinations for event E6BBF691... of type start 13:56:40 - No destinations for event E6BBF691... of type update Questions for Apple Engineering Are there known issues with ActivityKit push notifications specifically on iPhone 16 Pro Max devices? What additional diagnostic logs (system, APNs, liveactivitiesd) would be most helpful to collect? Could device-specific power management, notification settings, or OS-level changes on Pro Max models affect Live Activity updates? Are there differences in how Live Activity push subscriptions or routing are handled on iPhone 16 Pro Max vs Pro that could lead to this issue?

Code: func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { print("📶 收到 VoIP 推送: (payload.dictionaryPayload)") JPUSHService.handleVoipNotification(payload.dictionaryPayload) // 解析来电信息 guard let voipInfo = payload.dictionaryPayload["_j_voip"] as? [String: Any] else { completion() return } let caller = voipInfo["relationship"] as? String ?? "未知来电" apiUserId = "\(voipInfo["apiUserId"] ?? "")" let callUUID = UUID() // 关键：直接调用 reportIncomingCall // 虽然 Task 是异步的，但我们已经用 @preconcurrency 标记了类 // 并且 PushKit 的 completion 会在之后立即调用 self.reportIncomingCall(uuid: callUUID, callerName: caller) // 立即调用 PushKit completion completion() } private func reportIncomingCall(uuid: UUID, callerName: String) { print("========来电了============="); currentCallUUID = uuid isCallNotAnswered = true let handle = Handle( type: .generic, value: callerName, displayName: callerName ) var update = Conversation.Update( localMember: handle, members: [handle], activeRemoteMembers: [handle] ) // 👇 关键：设置通话能力为支持视频和播放铃声 update.capabilities = [.video, .playingTones] // ✅ 修复数据竞争警告 Task { do { try await conversationManager.reportNewIncomingConversation(uuid: uuid, update: update) print("✅ LiveCommunicationKit 来电上报成功") } catch { print("❌ 来电上报失败: \(error.localizedDescription)") } } } When the app is in the background and VoIP messages arrive, the program crashes. The error message is:*** Assertion failure in -[PKPushRegistry _terminateAppIfThereAreUnhandledVoIPPushes], PKPushRegistry.m:349 *** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Killing app because it never posted an incoming call to the system after receiving a PushKit VoIP push.' *** First throw call stack: (0x18df82044 0x18b419abc 0x18d27d6d0 0x21cff5494 0x107486064 0x10747d19c 0x21cff46fc 0x10746c584 0x107486064 0x1074a6f98 0x10747c548 0x10747c484 0x18ded4b74 0x18de782c4 0x18de79a0c 0x1dad01454 0x1908991a4 0x190864a28 0x10435fa1c 0x1b4965f08) libc++abi: terminating due to uncaught exception of type NSException Debug session ended with code 9: Terminated due to signal 9

Hello! I’m building a VoIP app for iPhone and Apple Watch using PushKit and CallKit. I’m trying to understand the recommended watchOS architecture for this kind of setup. What we would like is for the watch to behave as an endpoint for incoming calls, so that when a call comes in the user can answer on either the iPhone or the watch. My understanding is that VoIP notifications are not supported on watchOS, so for incoming calls what we ended up having to do was send the watch a regular APNs alert notification and only start the actual call setup after the user interacts with it. This isn’t ideal, and the notification often appears a few seconds late. What we would like to be able to do is present the incoming call on the watch more like how FaceTime calls appear on Apple Watch. So I wanted to ask whether this is the intended pattern for a companion watchOS VoIP app. Is using a regular APNs alert notification the correct way to surface an incoming call on the watch, or is there a better supported approach? Thanks!

Hi Apple Team, We are facing an issue with Live Activities where the UI intermittently fails to render and shows a loader or blank state. After extensive debugging, we’ve identified that the failure happens during the rendering phase inside the system process (WidgetKit / liveactivitiesd), but there are no actionable signals exposed to the app. Problem: Live Activity launches successfully After a few updates or under certain UI conditions, it: stops rendering shows a loader / blank UI sometimes disappears No crash logs are generated No MetricKit diagnostics available for the extension Console logs show: Invalid frame dimension (negative or non-finite) Archive was nil. LiveActivity will be empty Sometimes because of memory pressure too The extension process appears to terminate silently Challenge Currently, there is no way to detect from the app side that: the Live Activity has failed to render the extension process has crashed/terminated the UI is no longer being updated Questions Is there any callback, delegate, or lifecycle hook that notifies when: a Live Activity rendering fails the extension process crashes or is terminated by the system? Is there any recommended way to detect a “broken” Live Activity state (e.g., stuck loader / non-updating UI)? Are there any diagnostic APIs or logs we can rely on in production to identify such failures? Is this considered expected behavior under certain system constraints (e.g., memory/rendering limits), and if so, are there guidelines to proactively detect or mitigate it? Goal We want to: proactively detect Live Activity failure log it for monitoring optionally fallback or recover gracefully Additional context: We fixed all the issues and the live activity is pretty stable. But asking for methods to track & fix such cases.

I'm working on an app, and currently, 2 things dont work: account creation and notifications. I want to find the root of why these errors are occurring, and I want to know if these errors are coming from Firebase, certain settings in Xcode not being checked, or my actual written code not being typed correctly. I've tried to run my issue through ChatGPT many times to pretty much no success, so any help on what to do so I can clear certain areas and make sure the bugs aren't from certain spots, and help me narrow down the issue would be great. Otherwise, if there are other guides or threads I can be linked to, and help me fully break down the issue, that would be great. Thank you for your time reading, and I hope I can get some advice.

Hi everyone, I'm running an Apple MDM service and encountering an issue where a number of devices stop receiving MDM push commands within 10 days of profile installation, even though everything appears to be set up correctly. Environment: MDM profile is installed and verified (status: OK, result: SUCCESS) Devices are cellular-enabled with no connectivity issues APNs certificate is valid (thousands of other devices are communicating normally) The command being sent to devices is DeviceInformationCommand No "NotNow" response or any check-in received from the affected devices for over a week Issue: We send DeviceInformationCommand to devices to retrieve device information and update the last communication timestamp. However, a subset of devices simply stop responding to this command within 10 days of profile installation. The last communication date is not being updated, and no response — not even a "NotNow" — is coming back from these devices. Since other devices on the same MDM setup are working fine, I've ruled out APNs certificate expiration and general server-side issues. Questions: Are there any known management points or configuration settings that could cause a device to silently stop receiving DeviceInformationCommand shortly after enrollment? What diagnostic steps would you recommend to identify the root cause on the device or server side? Are there any known bugs or reported issues related to this behavior in recent iOS versions? Is there any way to recover the MDM communication without requiring the user to re-enroll? Any insights or suggestions would be greatly appreciated. Thank you!

I am getting InvalidProviderToken for every APNs key I create under my team. This has persisted for over a week across 3 different fresh keys. Setup: Team ID: QJLCAXKWMB Bundle ID: com.trackntakeit.app All keys: Team Scoped, All Topics, Sandbox & Production JWT: ES256, correct kid and iss fields Tested directly from Mac via curl with fresh tokens The key file is a valid EC 256-bit private key. JWT is correctly formed. Both production and sandbox endpoints return InvalidProviderToken. Case number with Apple Developer Support: 102857626802 Has anyone seen all APNs keys for an entire team being rejected? Could there be an account-level block on APNs?

Hi everyone, I have a SwiftUI app using CKQuerySubscription on the public database for social notifications (friend requests, recommendations, etc.). Push notifications work perfectly in the Development environment but never fire in Production (TestFlight). Setup: iOS 26.4, Xcode 26, Swift 6 Container: public database, CKQuerySubscription with .firesOnRecordCreation 5 subscriptions verified via CKDatabase.allSubscriptions() registerForRemoteNotifications() called unconditionally on every launch Valid APNS device token received in didRegisterForRemoteNotificationsWithDeviceToken Push Notifications + Background Modes (Remote notifications) capabilities enabled What works: All 5 subscriptions create successfully in Production Records are saved and queryable (in-app CloudKit fetches return them immediately) APNS production push works — tested via Xcode Push Notifications Console with the same device token, notification appeared instantly Everything works perfectly in the Development environment (subscriptions fire, push arrives) What doesn't work: When a record is created that matches a subscription predicate, no APNS push is ever delivered in Production Tested with records created from the app (device to device) and from CloudKit Dashboard — neither triggers push Tried: fresh subscription IDs, minimal NotificationInfo (just alertBody), stripped shouldSendContentAvailable, created an APNs key, toggled Push capability in Xcode, re-deployed schema from dev to prod Additional finding: One of my record types (CompletionNotification) was returning BAD_REQUEST when creating a subscription in Production, despite working in Development. Re-deploying the development schema to production (which reported "no changes") fixed the subscription creation. This suggests the production environment had inconsistent subscription state for that record type, possibly from the type being auto-created by a record save before formal schema deployment. I suspect a similar issue may be affecting the subscription-to-APNS pipeline for all my record types — the subscriptions exist and predicates match, but the production environment isn't wiring them to APNS delivery. Subscription creation code (simplified): let subscription = CKQuerySubscription( recordType: "FriendRequest", predicate: NSPredicate(format: "receiverID == %@ AND status == %@", userID, "pending"), subscriptionID: "fr-sub-v3", options: [.firesOnRecordCreation] ) let info = CKSubscription.NotificationInfo() info.titleLocalizationKey = "Friend Request" info.alertLocalizationKey = "FRIEND_REQUEST_BODY" info.alertLocalizationArgs = ["senderUsername"] info.soundName = "default" info.shouldBadge = true info.desiredKeys = ["senderUsername", "senderID"] info.category = "FRIEND_REQUEST" subscription.notificationInfo = info try await database.save(subscription) Has anyone encountered this? Is there a way to "reset" the subscription-to-APNS pipeline for a production container? I'd really appreciate any guidance on how to resolve and get my push notifications back to normal. Many thanks, Dimitar - LaterRex

We have an iPhone app with a companion watchOS app for factory alert monitoring. What we want to achieve is: each server event is an independent event, not just a latest-state update events should not be dropped in some scenarios, new events may arrive as frequently as once per minute the watch app state/UI should reflect the event almost in real time our target is roughly within 5 seconds the watch app is expected to be opened by the user when they want to confirm details, but we want the data to already be there even if the watch app was previously in the background notification mirroring is already sufficient for immediate user awareness; the question is about reliable background data/state delivery to the watch app Our current architecture is: The server sends APNs pushes to the iPhone app. We use both: alert pushes for user-visible notifications background pushes (content-available: 1, apns-push-type: background, apns-priority: 5) for background data delivery When the iPhone app receives the push, it relays data to the watch using WatchConnectivity. On the iPhone/watch side: we use sendMessage when reachable / foreground-like communication is possible we use transferUserInfo as the background / unreachable fallback The devices are paired and connected, and the apps are not force-quit. In practice, the behavior is not stable enough for this requirement: some background deliveries are delayed some relays to the watch are not timely the end-to-end behavior is not reliable enough for independent event delivery with near-real-time expectations My understanding is that: APNs background pushes are not guaranteed and may be throttled WatchConnectivity background delivery is opportunistic immediate WC messaging depends on reachability / active state So the main question is not how to debug a single implementation issue, but whether our expectation is valid at all on Apple platforms. Questions: Is this architecture fundamentally unsuitable if the requirement is lossless, near-real-time event delivery from server -> iPhone -> watch, with a target of roughly within 5 seconds? Even if the implementation is correct, should we expect iPhone background push + WatchConnectivity relay to remain inherently non-deterministic for this kind of requirement, especially in scenarios where events may occur approximately once per minute? If notification mirroring is used only for user awareness, but the watch app still needs reliable background state/data delivery before the user opens it, is there any Apple-supported architecture for that? Would direct delivery to the watch app be the only realistic direction, or is this level of reliability/latency simply not a supported expectation for general-purpose apps? We understand that background execution and delivery are managed opportunistically by the system. What I want to confirm is whether this requirement itself is outside the practical/supported envelope of APNs background push + WatchConnectivity relay.

Hello guys, We have updated our app icon, and it is correctly reflected in our app build and assets. However, the push notification icon is still displaying the old version for some users. ✅ We have verified that: All icon assets in Assets.xcassets match the new icon. The app icon has been updated in Info.plist. The app has been resubmitted and approved on the App Store. ❌ However, some users still see the old notification icon, even after reinstalling the app. Restarting the device does not always resolve the issue. Could you provide insights into how iOS caches notification icons and how we can force a refresh for all users?

I am working on a large-scale e-commerce application and we are trying to solve a specific issue regarding push notifications and user experience. We have a use case where we need to send a standard push notification to the user, but under certain local conditions on the device, we want to intercept that notification via a Notification Service Extension and suppress/drop it so it does not alert the user. We understand that the com.apple.developer.usernotifications.filtering entitlement allows a Notification Service Extension to drop notifications. However, looking at the entitlement request form, the categories seem strictly limited to: End-to-end encrypted messaging Earthquake warnings Education/learning platforms Enterprise healthcare apps My questions for the community and Apple staff: Is it possible for an e-commerce or retail app to be approved for this entitlement if we have a highly specific, valid use case that improves user experience. If this entitlement is strictly off-limits for our domain, what is the Apple-recommended architecture to achieve this? Thank you in advance for any insights or guidance!

Good day) Colleagues, please tell me how can I change the notification on the locked screen "pass changed" in PKPASS when changing several fields? Thank you very much for your answer